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(54) Integrated insurance system and system method 



(57) A computerised integrated insurance financing 
system. Specifically, the computerised insurance sys- 
tem is capable of handling an insurance transaction 
from the development of an appropriate insurance con- 
tract with the client through the management of the cli- 
ent's insurance information during the life of the 
contract. Initially, census data is received from a poten- 
tial client in the form of computer records representing a 
plurality of individuals to be insured. After being 
reviewed and standardised, the census data is used to 
perform a pecuniary loss analysis The data from the 
pecuniary loss analysis is used to generate insurance 
illustrations and a financial analysis for the client. Once 
an appropriate insurance contract is finalised, the sys- 
tem generates the insurance contract, and related doc- 
umentation, and the census data is used to manage the 
client's insurance information during the life of the con- 
tract. 
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Description 

[0001] The invention relates to a computer network 
and to a computerised integrated insurance financing 
system. More particularly, the computerised insurance 
system is capable of handling an insurance transaction 
from the development of an appropriate insurance con- 
tract with a client through the management of the cli- 
ent's insurance information during the life of the 
contract. 

[0002] As used herein "client" includes an offshore 
captive corporation or trust which is a purchaser or 
potential purchaser of life insurance for the purpose of 
funding or financing benefit liabilities in favour of its par- 
ent corporation or grantor. Initially, census data is 
received from a client in the form of computer records 
representing a plurality of individuals to be insured. 
After being reviewed and standardised by the computer 
system, the census data is used to perform a pecuniary 
loss analysis. Asset requirements are measured based 
upon insurance liabilities and/or employee benefit liabil- 
ities. The data from the pecuniary loss analysis and the 
asset measurements are then analyzed by the compu- 
ter system in order to generate life insurance coverage 
amounts consistent with applicable insurable interest 
laws, insurance liabilities and/or employee benefit liabil- 
ities. Insurance illustrations and a detailed financial 
analysis are provided for the client Once an appropriate 
life insurance contract is finalised, the system generates 
the life insurance contract and related documentation. 
All of the data previously generated is used to automat- 
ically manage by the computer system the client's insur- 
ance information during the life of the contract. 
[0003] The present invention is also directed to the 
computerised design, sale and management of life 
insurance plans for offshore captive insurance compa- 
nies located outside of the United States and offshore 
trusts located outside of the United States except Volun- 
tary Employee Beneficiary Associations (VEBA's) in 
which the client or trust insures a large number of indi- 
viduals, such as employees, under a single group con- 
tract or several individual contracts. Such an insurance 
contract might be used to finance insurance liabilities, 
employee death benefits, worker's compensation bene- 
fits, health insurance benefits, disability income benefits 
and nonqualified retirement benefits. Such an insur- 
ance plan can provide tax benefits to a client if the con- 
tract qualifies as insurance under applicable laws. 
[0004] Two possible uses for such a computerised 
integrated insurance system are 1) the automated 
design, sale and management of offshore captive insur- 
ance programs and 2) the automated design, sale and 
management of offshore trusteed insurance programs. 
A captive insurance company or a company sponsored 
trust, can accept contributions from a parent corrpany 
to insure employees of related entities for the purpose of 
financing various insurance liabilities and employee 
benefit liabilities. 



[0005] With use by a captive, the captive insurance 
company pays premiums to an offshore life insurance 
company. The computer system determines the amount 
of available insurance coverage under applicable insur- 

s able interest laws, measures captive insurance com- 
pany assets needed to satisfy insurance liabilities and 
determines the amount of assets which may be effi- 
ciently deployed in insurance contracts to improve after- 
tax investment yields, minimise investment risk, satisfy 

10 future liquidity requirements and shift insurance risk 
from the captive insurance company to an offshore 
insurance company. 

[0006] With use by a client sponsored offshore trust 
(except a VEBA) the trust pays premiums to an offshore 

15 life insurance company. The computer system deter- 
mines the amount of insurance coverage available 
under applicable insurable interest laws, determines the 
amount of employee benefit liabilities and measures the 
amount of assets required to finance those liabilities. 

20 The computer system then illustrates information on 
how to efficiently deploy those assets in life insurance 
contracts to improve after-tax investment yields, mini- 
mise investment risk, satisfy future liquidity require- 
ments and shift insurance risk from the trust to an 

25 offshore insurance company. 

[0007] Known computerised insurance systems are 
unable to handle an insurance transaction from the 
complete development of an appropriate insurance plan 
through the management of the client's insurance infbr- 

30 mation during the life of the contract. This is particularly 
true with respect to companies which have complex 
insurance liabilities and/or complex employee benefit 
liabilities and insure a large number of individuals in a 
single transaction. In general, known insurance systems 

35 are quite limited in that they do not encompass most or 
all functions required to perform a complete computer- 
ised integrated process which encompasses develop- 
ment, analysis, production and management of an 
insurance contract. Thus, known insurance systems are 

40 fragmented and utilise separate pecuniary loss analyz- 
ers, illustrators, insurance liability measurement sys- 
tems, benefit liability estimation systems, asset 
measurement systems and client insurance information 
management programs. 

45 [0008] Because presently known insurance systems 
handle an insurance transaction in a fragmented man- 
ner, they lack the oohesiveness, flexibility and econo- 
mies of scale that a computerised integrated insurance 
system would provide If the insurance transaction were 

so integrated and streamlined, the reduced cost could be 
passed along to the client. Increased profits on the sale 
of such insurance are also possible. 
[0009] Moreover, since data generated by one known 
insurance system must be transferred from system to 

55 system during the transaction, many of which are not 
compatible, it takes significantly longer to complete than 
if the entire process were integrated in a single compu- 
ter system. Given the length of time required to perform 



2 



3 



EP0 935 208 A2 



4 



pecuniary loss analysis, financial analyses, measure 
insurance and liabilities employee benefit liabilities, 
determine asset requirements, and generate financial 
computer-based illustrations, only a small number of 
scenarios are generally created for a company whether 5 
by a computer or manually. Further, the ease with which 
interdependent computer calculations can be made is 
lacking. An integrated computerised insurance transac- 
tion, on the other hand, enables a large number of differ- 
ent insurance scenarios to be easily generated for a 10 
prospective client based on that client's individual needs 
in a timely and cost efficient manner. The financial impli- 
cations of the various plans can also be quickly shown 
to the client on a cost efficient basis. Moreover, the 
plans can be rapidly modified based on feedback from 15 
the client This greater flexibility allows optimum cost 
efficient insurance plans to be generated for the client. 
[0010] It is thus apparent from the above that there 
exists a significant need in the art for a computer based 
integrated insurance system. 20 
[001 1 ] It is therefore an aim of preferred embodiments 
of this invention to provide an integrated computerised 
insurance system capable of handling transactions in 
which a plurality of individuals will be insured under a 
single group contract or several individual contracts. ss 
[0012] It is another aim of preferred embodiments of 
this invention to provide an integrated computerised 
insurance system capable of handling an insurance 
transaction more quickly and efficiently, resulting in 
more precise measurements, than non-integrated insur- 30 
ance systems. 

[0013] It is another aim of preferred embodiments of 
this invention to provide a computerised insurance sys- 
tem capable of inputting client census data, performing 
pecuniary loss analysis, measuring insurance liabilities, 35 
measuring employee benefit liabilities, determining 
asset requirements, performing a comprehensive finan- 
cial analysts, generating the final insurance contract 
and managing the client's insurance information during 
the life of the contract 40 
[0014] Briefly described, the present invention pro- 
vides a computer system which smoothly integrates 
these functions in an integrated computer architecture 
which is capable of designing and managing an insur- 
ance contract. 45 
[001 5] The present invention also provides a compu- 
terised method for implementing an integrated insur- 
ance system, comprising the steps of: (1) inputting 
client census data for a plurality of individuals in the 
form of computer records; (2) automatically performing so 
a pecuniary loss analysis on the census data to classify 
individuals into cells and determine appropriate insur- 
ance coverage amounts under applicable laws; (3) 
automatically determining asset requirements based 
upon insurance liabilities and employee benefit liabili- ss 
ties; (4) performing a computerised financial analysis 
based upon captive insurance company asset require- 
ments and/or trust asset requirements; (5) preparing 



computer-generated insurance illustrations based on 
the results of the pecuniary loss analysis, the measure- 
ments of assets and underlying insurance liabilities and 
employee benefit liabilities; (6) creating a final insurance 
contract and related documentation; and (7) managing 
through such computer system the client's insurance 
information and assets utilised to offset insurance and 
employee benefit liabilities during the life of the contract. 
[001 6] The present invention also provides an appara- 
tus for implementing an integrated insurance system, 
comprising: (1) an inputting census data unit for a plu- 
rality of individuals in the form of computer records; (2) 
a pecuniary loss analyzer for the census data to classify 
individuals into cells and determine appropriate insur- 
ance coverage amounts under applicable laws; (3) an 
asset requirements unit to determine asset require- 
ments based ipon insurance liabilities and employee 
benefit liabilities; (4) a financial analysis unit to perform 
a financial analysis based upon captive insurance com- 
pany asset requirements and/or trust asset require- 
ments; (5) an illustrator for preparing insurance 
illustrations based on the results of the pecuniary loss 
analysis, the measurement of assets and underlying 
insurance liabilities and employee benefit liabilities; (6) 
a document generator for creating a final insurance con- 
tract and related documentation; and (7) a managing 
unit to manage the client's insurance information- and 
assets utilised to offset insurance and employee benefit 
liabilities during the life of the contract. 
[001 7] The present invention provides the features set 
out in the appended claims. 

Figure 1 is a block diagram of the hardware 
arrangement used in a preferred embodiment of the 
present invention. 

Figure 2 is a block diagram of the functional compo- 
nents of a preferred embodiment of the present 
invention. 

Figure 3 is a block data flow overview diagram 
according to a preferred embodiment of the present 
invention. 

Figures 4A to 4C are block flow diagrams showing 
the integrated insurance system according to a pre- 
ferred embodiment of the present invention. 

Figures 5A to 5H are block flow diagrams showing 
the census data analysis process according to a 
preferred embodiment of the present invention. 

Rgure 51 is a sample menu displayed during the 
census data analysis according to a preferred 
embodiment of the present invention. 

Figures 6A to 6J are block flow diagrams showing 
the pecuniary loss analysis process according to a 
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preferred embodiment of the present invention. 

Figures 7A to 7D are block flow diagrams showing 
the insurance illustration process according to a 
preferred embodiment of the present invention. 

Figures 8A and 8B are block flow diagrams showing 
the financial analysis process according to a pre- 
ferred embodiment of the present invention. 

Figures 9A to 9E are block flow diagrams showing 
the client information management process accord- 
ing to a preferred embodiment of the present inven- 
tion. 

[0018] Referring now in detail to the drawings wherein 
like parts are designated by like reference numerals 
throughout, there is illustrated in Figure 1 a diagram of 
the hardware arrangement used in a preferred embodi- 
ment of the present invention. An Ethernet backbone 10 
connects a number of workstations 20, servers 30, 40, 
50 and printer 70. The workstations 20 can be IBM PC 
compatible machines, running Microsoft MS-DOS and 
Windows 3. 1 . 1 , or Microsoft Windows NT, versions 3.51 
and higher. The workstations 20 require the following 
hardware components: 16MB of RAM, a 500MB hard 
drive, and a colour VGA video display. It should be 
noted, however, that other components can be used. 
[0019] The database server 30, the file server 40 and 
the backup server 50 can be Intel Pentium based IBM 
PCs running Novell Netware versions 3.11 or higher, or 
Microsoft Windows NT Server version 3.51 or higher. 
Each server 30, 40, 50 requires the following minimums: 
64MB RAM and a hard drive. 
[0020] The database server 30 accepts queries from 
workstations 20 and returns data sets from a central- 
ised database. The database server 30 also provides 
data warehousing, backup and data fault tolerance. 
[0021 ] The file server 40 performs file and print shar- 
ing services and authenticates internal login requests. 
The file server 40 can also handle external data flow via 
modems 60. 

[0022] The backup server 50 provides fault tolerance 
through continuous on-line backup to tape, and can 
double as the file server 40 or the database server 30 in 
the event either server fails. 

[0023] It will be understood by those skilled in the art 
that this hardware embodiment is only one of many 
ways that can be used to implement the integrated 
insurance system. Although multiple server and work- 
station processors are shown, their functions could be 
handled by a single computer if multi-user access is not 
required. Alternately, instead of the Ethernet backbone 
10 the various processors could be connected through 
other local area network (LAN) topologies such as 
Token-Ring, wide area networks (WAN), switched tele- 
phone networks, such as a public or packet switched 
network environment such as the Internet. Internet con- 



nectivity enhances the system to provide World Wide 
Web access to databases, and the transmission and 
reception of e-mail Messaging to automate client report- 
ing, and claim notification from remote sites. For exam- 

s pie, census data or claim information could be received 
from a remote site through the Internet. 
[0024] Figure 2 is an overview diagram of the func- 
tional components of a preferred embodiment of the 
present invention. The census analyzer 500 receives 

10 raw census data from the client. As explained in detail 
with respect to Figures 5A to 51, the census analyzer 
can (1) review input census data representing a plurality 
of people to be insured; (2) provide a subset of data to 
a third party for validation; (3) compare present census 

15 data with past census data from the same client; and (4) 
convert the census data into a standardized format. 
[0025] After the census data has been standardized 
by the census analyzer 500, the pecuniary loss analyzer 
600 processes the data based on input control parame- 

20 tens. As explained in detail with respect of Figures 6A to 
6J, the pecuniary loss analyzer 600 calculates the insur- 
able interest that a potential client has in each individual 
in the census. The pecuniary loss analyzer 600 catego- 
rises each individual to be insured and places them in a 

2$ representative "cell". 

[0026] These cells of data are used by the illustrator 
700. As explained in detail with respect of Figures 7A to 
7D, the illustrator 700 adjusts the data in the cells and 
generates insurance ledgers for presentation to a 

30 potential client. The financial analyzer 800 also gener- 
ates reports regarding the potential client, as explained 
in detail with respect to Figures 8A and 8B. Next, the 
final contract generator 100 creates the final contract 
and related documentation. Finally, the insurance plan 

35 is administered by the client insurance information man- 
ager 900 as explained in detail with respect to Figures 
9Ato9E. 

[0027] Figure 3 is a data flow overview diagram of a 
preferred embodiment of the present invention. Data is 

40 received from a potential client by the census analyzer 
500 in the form of input census data 90. The census 
analyser 500 can also access prior census data 91 from 
the same client. The input census data 90 and prior 
census data 91 can be compared to generate census 

45 comparison reports. The census analyzer also converts 
the input census data 90 into a standardised format as 
represented by standardised census data 92. 
[0028] The standardised census data 92 is used by 
the pecuniary loss analyzer 600, along with operator 

so input control parameters, to classify individuals into rep- 
resentative cells 80. The cells 80 are adjusted by the 
illustrator 700 and are used by the financial analyzer 
800 to create reports based on operator input control 
parameters. When an appropriate contract is approved, 

55 the final census data 95 is created. The final census 
data 95 is used by the client insurance information man- 
ager 900 to administer the insurance plan. The adminis- 
tration of the plan includes the generation of death 
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benefit paper work, claim status results and financial 
reports to client 

Process Overview 

[0029] Figures 4A to 4C are block flow diagrams 
showing an overview of the process of the integrated 
insurance system according to a preferred embodiment 
of the invention. 

[0030] As shown in Figure 4A, census data is received 
from a potential client (step 400) and reviewed (step 
402). This process is described in greater detail with 
respect of Figures 5A to 51. The data is then input to the 
pecuniary loss module (step 404). 
[0031] A pecuniary loss analysis is conducted on an 
aggregate and an individual basis (step 405). This proc- 
ess is described in greater detail with respect to Figures 
6A to 6J. The results of the pecuniary loss analysis are 
reviewed and analyzed by the client (step 406). If the 
results are not satisfactory, the assumptions used dur- 
ing the pecuniary loss analysis can be revised and the 
pecuniary loss analysis can be repeated (steps 408 and 
410). 

[0032] If the results of the pecuniary loss analysis are 
satisfactory, life insurance projections, or illustration 
ledgers, are produced (step 412) and a financial analy- 
sis is performed as shown in Figure b (step 414V v Jhese 
processes are described in greater detail with respect to 
Figures 7A to 7D and 8A and 8B. The results of the 
insurance illustration and financial analysis can then be 
reviewed (step 416). If the results are not satisfactory, 
the assumptions used during the insurance illustration 
and financial analysis can be revised and these func- 
tions can be repeated (steps 418 and 420). 
[0033] When the result of all of the above steps is opti- 
mized, the client decides whether or not insurance will 
be purchased. If insurance is not purchased, that is the 
end of the transaction (steps 422 and 424). If insurance 
is purchased, the case is underwritten and issued and 
the system generates the final insurance contract and 
related documentation (step 428). 
[0034] Once the contract is in effect, the system can 
administer the insurance plan. This process is 
described in greater detail with respect to Figures 9A to 
9E. The plan's administration includes processing death 
benefit claims as shown in Figure 4C (step 430). The 
system can also update monthly asset values and mon- 
itor the value of funds in the plan (step 432). Financial 
reports for the insurance company are generated and 
all relevant data is stored (steps 436 and 438). Finally, 
the system can prepare an annual plan review, showing 
historical financial performance and re-projecting future 
performance based on updated assumptions, to be pre- 
sented to client (steps 440 and 442). 

Census Data Analysis 

[0035] The insurance transaction begins when raw 



census data is received from the client. The census 
data contains a plurality of computer records represent- 
ing the individuals to be insured. Such a computer 
record might contain the individual's name, social secu- 

s rity number, sex, date of birth and salary. The received 
census data is reviewed for completeness and stand- 
ardized. Newly received census data can be compared 
to census data previously received from the same dient 
to determine which individuals have been added or 

w deleted. The system also generates a computer file that 
can by used by a third party to verify that the social 
security numbers are valid. Figures 5A to 5H are block 
flow diagrams showing this census data analysis proc- 
ess. 

15 [0036] As shown in Figure 5A, the user is first pre- 
sented with a menu listing the census data analysis 
choices (step 510). Such a menu is shown in Figure 51. 
The menu includes an option to return to the higher 
level menu (step 512), select a help screen (step 514), 

20 save the parameters currently entered (step 516) or 
load a set of parameters that were previously stored 
(step 518). 

[0037] The user can also select to perform a census 
data analysis (step 520). First parameters are con- 

sb verted to usable alpha or numeric formats (step 521). 
These values are then verified to determine, for exam- 
pie, that the date of birth is valid, (step 522) and tested 
for overlap of specified fields on output files (step 523). 
Next, the disk files are opened (step 524) and the sys- 

30 tern is ready to perform the process shown in Figure 5B. 
[0038] The processes shown in Figures 5B to 5Q 
compare the input client census data, or the Update 
File, with previously received client census data, or the 
Master File. The Update File represents the input cen- 

35 sus data 90 and the Master File represents the prior 
census data 91 shown in Figure 3. The comparison 
generates three output files: (1) a list of individuals in 
both the input and the previously received census data 
called the Match File; (2) a list of individuals added to 

40 the census called the Unmatched date File; and (3) a list 
of individuals deleted from the census called the 
Unmatched Master File. It is important to note that both 
the Master and Update Files are sorted by their social 
security number or any other unique identifier "Key" to 

45 simplify the comparison. 

[0039] As shown in Figure 5B if both the end of the 
Master File (End=Y) and the end of the Update File 
(End=Y) have been reached.the comparison is finished 
and the process shown in Figure 5H is executed (step 

so 525). If End=Y, End=N and the end of the Update File 
has been reached, SEPTATE is set to infinite and the 
process shown in Figure 5C is executed (steps 527 and 
528). If End=N and the end of the Update File has been 
reached, the process shown in Figure 5C is executed. If 

55 both End and End are not Y, and it is not the end of the 
Update File (step 526), an update record is read and the 
update count is increased (steps 529 and 555). 
[0040] The number of ipdate records that have been 
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read is displayed (step 556) and the social security 
number, or "key," is extracted and verified (step 557). 
The system checks tor duplicate update records (step 
558) and the process shown in c is executed. 
[0041] As shown in Figure 5C, if both End=Y and 
End=Y ( the comparison is finished and the process 
shown in Figure 5H is executed (step 548). if End=Y, 
End=N and the end of the Master File has been 
reached, SSMast is set to infinite and the process 
shown in Figure 5D is executed (steps 552 and 554). If 
End=N and the end of the Master File has been 
reached, the process shown in Figure 5D is executed. If 
both End and End are not Y, and the end of the Master 
File has not been reached (step 550), a master record is 
read and the master count is increased (step 559 and 
560). 

[0042] The number of master records that have been 
read is displayed (step 561 ) and the key is extracted and 
verified (step 562). The system then checks for dupli- 
cate master records (step 563) and the process shown 
in Figure 5D is executed. 

[0043] As shown in Figure 5D, a social security 
number in the Master File is compared to a social secu- 
rity number in the Update File. If the social security 
number in the Master File, or SSMast, is less than the 
social security number in the Update File, or SEPTATE, 
a terminated employee has been detected and the proc^ 
ess shown in Figure 5E is executed (step 564). ff 
SSMast is greater then SEPTATE, a new participant is 
detected and the process shown in Figure 5F is exe- 
cuted (step 565). 

[0044] If SSMast is equal to SEPTATE, (step 570) a 
match has been found. The matched count is therefore 
increased by one and a matched record is built from the 
Master and Update Files (steps 570 and 572). The 
matched record is written to the match file (step 574). If 
the end of the Master File has been reached, End is set 
to Y, SSMast is set to infinite (steps 576, 578 and 582). 
If the end of the Master File has not been reached and 
the End of the Update File has been reached, End is set 
to Y and SEPTATE is set to infinite (steps 580, 581 and 
583). In any event, the process shown in Figure 5E is 
executed. 

[0045] The process executed when a terminated par- 
ticipant has been discovered, that is a record has been 
found in the Master File that is not present in the Update 
File, is shown in Figure 5E. If End equals N, the 
unmatched master count is increased by one and, if 
desired, an unreported master record is built and written 
to the unreported master file (steps 584, 530, 531, 532 
and 533). 

[0046] ff the end of the Master File is not detected, the 
process shown in Figure 5C is executed (step 534). If 
the end of the Master File is detected, End is set to Y, 
SSMast is set to infinite and the process shown in Fig- 
ure 5F is executed (steps 535 and 536). 
[0047] The process executed when a newly added 
participant has been discovered, that is a record has 



been found in the Update File that is not present in the 
Master File, is shown in Figure 5F. If End equals N, the 
unmatched master count is increased by one and, if 
desired, an unreported master record is built and written 
s to the unreported Master File (steps 537, 538, 539, 540 
and 541). 

[0048] ff the end of the Update File is not detected, the 
process shown in Figure 5G is executed (step 542). If 
the end of the Update Pile is detected, End is set to Y, 

10 SSUpdate is set to infinite, and the process shown in 
Figure 5G is executed (steps 543 and 544). 
[0049] As shown in Figure 5G, if both the end of the 
Master File (End=Y) and the end of the Update File 
(End=Y) have been reached, the comparison is finished 

is and the process shown in Figure 5H is executed (step 
545). ff End or End are N and the end of the Update File 
has been reached, the process shown in Figure 5D is 
executed (step 564). If End or End are N and the end of 
the Update File has not been reached, the next update 

20 record is read and the update count is increased by 1 
(steps 547 and 585). The number of update records is 
displayed and the social security number or "key", is 
extracted and verified (steps 586 and 55). The system 
then checks for duplicate update records (step 551) and 

25, , the process shown in Figure 5D is executed. 

[0050] As shown in Figure 5H, at the end of the com- 

^^ pariso n. the data files are closed (step 587). A report is 
printed (step 588) listing the results in the form of (1) 
individuals in both the input and the previously received 

so census data; (2) individuals added to the census called 
the Unmatched Update File; and (3) individuals deleted 
from the census called the Unmatched Master File. 
[0051] Thus, as shown in Figures 5A to 5H, the cen- 
sus data analysis ("CDA") module can compare two dis- 

35 tinct sequential ASCII files, each comprised of fixed 
records of employee information. The fields in each 
record of one file can differ in form and substance from 
the fields in each record of the other file in all but one 
respect. Records in both files must each contain one 

40 "key" field, the value of which is unique within the file, 
and which is used as an identifier for that particular 
record. In the preferred embodiment, the social security 
number is used for this purpose. Both files are first 
sorted in order of the key and the program scans 

45 through both files simultaneously looking for records 
from both files with matching keys. Matching records 
contain a combination of data which relate to a single 
employee. The program take selected fields from each 
record to create a composite output record. 

so [0052] One input file is designated as the Master file 
while the other is referred to as the Update fife. The pro- 
gram allows the user to specify the disk location of each 
input file and to specify the location of the fields in each 
record of that file. The user then describes the desired 

55 layout of as many as three separate output files created 
as a result of the matching process. The first of a file of 
matched records where fields from both Master and 
Update records are merged together and selected to 
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create combined and updated output records. The next 
option is to create a file of unmatched Master records. 
The records on this ffle can be redesigned by the user 
from any of the fields on the Master File. Similarly, a file 
of unmatched Update records can be created. 5 
[0053] Consider a Master File of policy issue informa- 
tion tor all of the originally insured participants of a par- 
ticular client Several years after plan inception a current 
employee census is prepared. This Update file contains 
such items as current salary and state of residence. 
From the matched records, the CDA module is able to 
create a file of all current employees who were previ- 
ously insured. This single file could contain both policy 
data as well as current salary and state of residence 
information for each insured active employee. 
[0054] A file of records created or copied from the 
unmatched Master records could also be created. 
These would be records for people who were originally 
insured, but are not currently employed and are thus 
either terminated, retired or deceased. Finally, a file of 
information for potential new entrants to the plan could 
be created from the unmatched Update records of cur- 
rent employees. 

[0055] The program allows the flexibility to simply 
reformat the layout of existing files and create output 
files with any combination of either matched or 
unmatched Master o r U^^er eoords. It is also useful 



stored (step 618). 

[0058] When the appropriate control parameters have 
been entered or loaded, the user can also select to per- 
form the pecuniary loss analysis. Initially, parameters 
are converted to usable alpha or numeric formats (step 
620). 

[0059] A vector or stream of annual health cost trend 
rates is created (step 622). This process is described in 
detail in Figure 6G. The health cost trend rate is taken 
for each year and used to calculate a health cost (steps 
670, 671 and 674.). The process is repeated until either 
the ultimate rate or the individual's retirement age has 
been reached (steps 672 and 673). 
[0060] Referring back to Figure 6A, a vector of pre- 
mium bands is created (step 623). This process is 
described in detail in Figure 6H. A maximum and mini- 
mum annual premium for each individual is selected for 
the client. For example, the client might wish to pay 
between $400 and $1,000 for each individual to be 
insured. A number of premium bands is also selected 
for the client. For example the client may wish to catego- 
rise individuals into three groups, or bands. The pre- 
mium band size is then computed (steps 680 and 682). 
Using the above examples, three bands would be cre- 
ated: $400 to $600; $600 to $800 and $800 to $1 ,000. 
The bands are displayed (steps 681 and 683) are com- 
puted, until the maximum premium is reached (step 
684). 

[0061] Returning to Figure 6A, the client's premium 
rates are loaded (step 624) and state workers* compen- 
sation benefit rates are computed as shown in Figure 
6B (step 625). 

[0062] As shown in Figure 6B, four brackets are set 
between the client's minimum and maximum premium 
values. The parameters for the states are verified and 
the standardized census data file is opened so that the 
data can be accessed (steps 627 and 628). A record 
representing an individual to be insured is read and the 
data is parsed into the appropriate fields (step 629) . The 
individual's applicable state, such as New York or Vir- 
ginia, and date of birth are then verified (steps 630 and. 
631). If the date of birth is not valid, it is set to an unre- 
alistic number, which forces the individual to be 
excluded form the insurance calculations. 
[0063] As shown in Figure 6C, the field representing 
the sex of the individual is verified. If the value of this 
field is not valid, it is to set to n M" for male, as a default. 
The 6ystem then sets a flag if the applicable state for the 
individual is an "active health" state (step 633). That is. 
the flag is set if the state considers the health costs for 
the individual to be recoverable. The age is calculated 
based on the individual's date of birth (step 634). The 
age is considered invalid if the individual is under 20 or 
over 65 years of age. 

[0064] If either (1) the age of the individual or (2) the 
state are not valid, nothing more can be done and the 
record for the next individual is read (step 635). 
[0065] If the age and state are valid, the normal retire- 
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for simply tabulating the total numbers of matched or 
unmatched records without ever having to create any 
output files. 30 

Pecuniary loss Analysis 

[0056] The reviewed and standardized census data is 
then used to perform a pecuniary loss analysis. Figures 35 
6A to 6J are block flow diagrams showing the pecuniary 
loss analysis process according to a preferred embodi- 
ment of the present invention. The analysis is based on 
a set of parameters controlled by the operator. For 
example, the operator might select projected rates of *o 
inflation over the life of the contract, the average amount 
of life insurance provided to employees based on their 
salary, the normal retirement age for employees, the 
maximum and minimum premiums the client wishes to 
pay per individual, and which state's (or country's) laws 45 
and regulations will be used in the analysis. As a result 
of the pecuniary loss analysis, each individual in the 
census is classified, or placed in a "cell", based on the 
insurable interest the client has in the individual. If the 
results of the pecuniary loss analysis are not acceptable so 
to the client, the parameters can be modified and other 
pecuniary loss analysis can be performed. 
[0057] As shown in Figures 6A, the user is first pre- 
sented with a menu listing the pecuniary loss analysis 
choices (step 610). The menu includes an option to 55 
return to the higher level menu (step 612), select a help 
screen (step 614), to save the parameters currently 
entered (step 616) or to load parameters previously 
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merit age (NRA) for the individual is calculated, which 
determines when health premium payments will no 
longer represent an insurable interest (steps 636 and 
637). After the normal retirement age is calculated, a 
determination is made: based upon user input, as to 
whether or not a non-qualified retirement income benefit 
liability (NQRIB) is present. If NQRIB is yes, then the 
NQRIB flag is set to T. The system then branches to 
the NQRIB module as shown in Figure 6J. Various 
parameters, some calculated, issue age, retirement 
age, some input, retirement payout period interest rates, 
plan type, are loaded (step 690). The system deter- 
mines whether the NQRIB is a defined benefit (DB) or 
defined contribution (DC) plan (step 691). 
[0066] In the case of a DB NQRIB, the benefit liability 
may be entered as flat amount or defined by formula 
(steps 692 , 694 and 697). If defined by formula, the 
expression evaluator will parse and load the benefit for- 
mula. 

[0067] In the case of a DC NQRIB, the deferral 
amount may be entered as a vector of deferral amounts 
or defined by formula (steps 693, 696 and 697). tf 
defined by formula, the expression evaluator will parse 
and load the deferral vector. 
[0068] Once the benefit/deferral amounts are loaded, 
the retirement income liability (RIL) payout is calculated 
i(step 698). The RIL is stored for later comparison to the 
CalcSumBen result as well as for use by the insurance 
illustration system, for targeting cash value and death 
benefit purposes. 

[0069] Returning to Figure 6C, after calculating the 
age to stop health premium payments (step 637) the 
process shown in Figure 6D is executed. As shown in 
Figure 6D, the health care premium cost per year for the 
individual's state is calculated step 640). This is done for 
all the specified states until the final year of the insur- 
ance contract, or the final year that health insurance will 
be provided for the individual, is reached (step 642). 
The workers' compensation survivor's benefit is calcu- 
lated based on the individual's salary (step 644). When 
the maximum benefits for all of the years have been 
determined, the sum of the individual's death benefit, 
health cost and workers' compensation is stored (step 
645). When the sum of all the benefits is calculated, the 
system checks to see if the NQRIB flag is set to N Y". 
When the flag is yes the system will reset the sum of all 
benefits to the lesser of RIL or the current sum of all 
benefits. 

[0070] This number represents the insurable interest 
the client has in the individual, not including life insur- 
ance. The process shown in Figure 6E is then executed. 
[0071] Returning now to Figure 6E, the individual's 
premium bracket is increased (step 654) or decreased 
(656) based on the new benefit value and the face insur- 
ance value (steps 651 , 652 and 653). The amount of life 
insurance based on the new premium bracket is re-cal- 
culated. These steps are repeated until an appropriate 
premium bracket is selected. When the appropriate pre- 



mium bracket is selected, a final benefit value is calcu- 
lated using the appropriate recovery amount and the 
value previously computed and stored in step 645 (step 
657). The process shown in Figure 6F is then executed. 

5 [0072] As shown in Figure 6F, if the total value of ben- 
efits is greater than the face amount (step 660), a valid 
record is established (step 661) and, after the appropri- 
ate counters are updated and the record is packed (step 
662), the output record is written. If the total value of 

10 benefits is not greater than the face amount, the user 
can select whether or not the record should be saved 
(step 664). In either case, if the end of the standardized 
census file has not been reached, the record for the next 
individual is processed (step 665). If the end of the 

15 standardized census file has been reached, the pricing 
and state analysis file is saved and pecuniary analysis 
reports are printed (steps 666 and 667). 
[0073] Thus, the pecuniary loss analysis combines 
information regarding several types of benefits, pro- 

20 vided to each member of a group of individuals in the 
census, with the individual's data. This is used to deter- 
mine the total of the client's insurable interest in each of 
the chosen individuals on a pecuniary loss basis. This 
pecuniary loss analysis may be subjected to situs con- 

25 straints of the transaction and or the residence of the 
insured. As this is done, the module determines an 
amount of life insurance for each employee that would , 
reimburse the employer for its insurable interest at the 
employee's death at a level no higher than the pecuni- 
ae ary loss. Generally, the amount of coverage is chosen 
as the amount provided by one of several fixed levels of 
premium, very similar to a defined contribution type 
approach. The program uses an iterative process to 
solve for the appropriate premium level. As an alterna- 

35 tive, the system may be given an aggregate employer 
benefit liability and would then calculate the insurance 
levels and premiums per insured, a defined benefit 
approach. 

[0074] Normally, the employer's estimated pecuniary 

40 loss is comprised of four components. First, the amount 
of the employer provided pre-retirement death benefit is 
determined. This is generally based upon a pay related 
formula including the application of a salary scale to 
anticipate future increases in the actual benefit. Next, 

45 the state of residence of each employee may be used to 
determine the specific workers' compensation survivor's 
benefit payable in that state. Assumptions are made as 
to each employee's dependent status at death. For 
employees residing in states (under the insured resi- 

so dence approach) with modern insurable interest stat- 
utes, a total of the trended employer provided health 
care cost is also included. Finally, an amount which rep- 
resents the accumulated value of the actual life insur- 
ance premium payments (time value adjusted) made by 

55 the employer is added to the other items. 

[0075] The module contains a great deal of flexibility 
in its ability to deal with specified groupings of employ- 
ees and special benefits unique to individual clients, ft 
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also generates various reports and data files which are 
used to communicate the results of its analysis and to 
provide input to other software for specific pricing and 
plan performance analysis. 

5 

Insurance Illustration 

[0076] The pecuniary loss analysis generates data in 
the form of representative "cells". These cells are used 
to create insurance illustrations, or ledgers, for the di- 10 
ent. Figures 7A to 7D are block flow diagrams showing 
the insurance illustration process according to a pre- 
ferred embodiment of the present invention. The ledg- 
ers are created based on another set of parameters 
controlled by the operator. These parameters might 15 
include the client's cash flow requirements and funding 
objectives. The illustration reviews, and if necessary 
revises, every cell for each year of the insurance con- 
tract. The review includes calculations to determine 
whether the contract is a modified endowment contract 20 
MEC) and comply with § 7702(b) of the Internal Reve- 
nue Code of 1986 as Amended ("Code"). As before, the 
input parameters can be modified, and another illustra- 
tion can be created, if the results of the illustration are 
not acceptable. 25 
[0077] As shown in Figure 7A, census data is created 
.* .. ; < ^*^and verified (steps 710 and 712). A menu is used to set 
up input parameters from the census data (step 714) 
and a compensation level, or profit level, is set for the 
sale of the insurance plan (step 716). Product loads, 30 
such as break points, state premium taxes and deferred 
acquisition cost ("DAC") tax considerations are calcu- 
lated (step 71 8) as are product cost of insurance ("COI") 
charges (step 720). Finally, a probability table repre- 
senting mortality assumptions is either read from a pre- 35 
stored file or generated (step 722) and the cash value 
and/or asset deployment allocation is read or calcu- 
lated. 

[0078] As shown in Figure 7B, cash flow parameters, 
such as the size of assets to be invested and the dates 40 
that assets are to be deposited to, or removed from, the 
plan, are defined (step 724). The client's funding objec- 
tives are also defined at this point (step 726). For exam- 
ple, the client may wish to build the cash value of the 
plan to a predetermined value by a specific date. 45 
[0079] A death benefit level is calculated based on the 
census data and the premium levels committed to by 
the client (step 728). Each cell is then analyzed and 
adjusted on a per year basis. The death benefit is 
increased based on the plan's qualification as a modi- so 
tied endowment contract ("MEC") (steps 730 and 732). 
This is because distributions from a MEC are taxed to 
the extent of any income in the contract and there can 
be an additional tax on the amount of any taxable 
income distributed from a MEC Also, loans from a MEC 55 
are treated and taxed as distributions. 
[0080] The death benefit is also increased based on 
compliance with Section 7702(f) (7) (b) of the Code 



steps 740 and 742). This is because section 7702 sets 
out certain requirements that a policy must satisfy in 
order to be considered life insurance" for tax purposes. 
The process then determines how to handle distribu- 
tions in excess of the basis (step 750). For example, it 
must be decided if loans on the plan will be allowed. 
Finally, the process shown in Figure 7C is executed. 
[0081 ] As shown in Figure 7C, current values and val- 
ues that will be guaranteed based on certain assump- 
tions are calculated (steps 752 and 754). These values 
are often required by the Securities and Exchange 
Commission (SEC) or state insurance regulators. If the 
last year of the contract has not been reached, the next 
year is then analyzed (step 756). Optionally, the process 
can also determine whether the calculated values are 
within present target ranges (steps 758 and 760). The 
target ranges may also be loaded from the values 
stored as retirement income liability from the pecuniary 
loss analysis, tf not, the target amounts can be updated 
and the analysis can be repeated (steps 764 and 766). 
If such targeting has not been selected, or if the values 
fall within the target ranges, the process of Figure 7D is 
executed (step 762). 

RnanpiQl Anplypis 

[0082] Figures 8 A and 8B are block flow diagrams 
showing the financial analysis process according to a 
preferred embodiment of the present invention. The pur- 
pose of the financial analysis process and financial ana- 
lyzer device is to analyze the insurance purchase and 
its financial impact on the client. The financial analysis 
can be conducted with respect to offshore captive asset 
deployment, as well as a company sponsored trust that 
funds employee benefit liabilities. The analysis meas- 
ures insurance cash value (assets), it's allocation 
among various investment strategies (short, intermedi- 
ate & long term), pre-tax and net after tax financial 
impact at various discount rates and the underlying cost 
structure of the insurance contract. Additionally, the 
analysis allows for matching of current and future liquid- 
ity requirements with cash flows that the insurance con- 
tracts generate, in terms of death benefits, cash value 
withdrawals and loans. The analysis clearly demon- 
strates the advantage to deploying assets offshore, 
through a captive insurance company, or a company 
sponsored trust. The financial analysis calculates the 
amount of assets that may be effectively deployed in 
insurance to maximise investment yields, minimise 
investment risk, shift insurance risk and satisfy future 
liquidity requirements. 

[0083] The system calculates approximately 150 dif- 
ferent tabulated variables that include the areas of: 
insurance analysts, income statement, balance sheet, 
cash flow analysis, earnings analysis, insurance prod- 
uct loads and expenses, alternative use of funds analy- 
sis, net present value analysis, earnings per share, 
return on investment, internal rates of return and the 
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ability to customise additional variables, on an ad-hoc 
basis, as the client may request These variables are 
tabulated and may be selectively chosen to generate 
standard, as well as customised, reports to meet the cli- 
ent's needs. 5 
[0084] Referring now to Figure 8A, the user is first pre- 
sented with a menu listing the financial analysis choices 
(step 810). The menu includes an option to return to the 
higher level menu (step 812), select a help screen (step 
814), to save the parameters currently entered (step 10 
816) or to load parameters previously stored (step 818). 
[0085] When the appropriate control parameters have 
been entered or loaded, the user can also select to per- 
form the financial analysis (step 820). Initially, a 100 by 
1 50 matrix is set up (step 822) and insurance illustration 15 
data is loaded (step 824). Corporate tax rates, discount 
rates and use of money rates can also be loaded (steps 
826, 828, 830). 

[0086] As shown in Figure 8B, a calculation method- 
ology is selected and all of the financial analysis calcu- 20 
lations are completed (steps 840, 850 and 860). After 
the calculations are complete, the report parameters 
can be loaded and the reports are generated (steps 
870, 880, 890). 

" 26 

Client Information Management 

[0087] Once an appropriate insurance contract is 
finalised, the system generates the insurance contract, 
and related documentation, and the census data is used 30 
to manage the client's insurance information during the 
life of the contract. Figures 9A to 9E are block flow dia- 
grams showing the client information management 
process according to a preferred embodiment of the 
present invention. At this point, the census data is fro- 35 
zen and used to manage the client's insurance related 
information. Death benefit claims can be processed, an 
individual's insurance data can be edited and financial 
reports can be generated for the client. Because the 
insurance system is entirely integrated, all of these 40 
functions are automated. 

[0088] System Administrators have access to insur- 
ance information for multiple clients and to housekeep- 
ing and databases directly. System Administrators are 
presented with a menu (step 906) that allows them to 45 
return to the main menu (step 909). This menu also lets 
the user: sweep a database as described with respect 
to Figure 98; perform data management; and perform 
finance and accounting functions. 
[0089] As shown in Figure 9B, when the System so 
Administrator elects to perform a sweep, an output file is 
created containing the social security number of the 
insured individuals which is then sent to a third party for 
validation (step 980). Sweep results are received from 
the third party, imported into the system and displayed 55 
(steps 981 and 982). Next, the data is reviewed and dis- 
crepancies are identified and flagged as described with 
respect of Figure 9C (step 970). Invalid social security 



numbers are resolved and, if necessary, death benefit 
claim are generated. The client is notified of any dis- 
crepancies (step 983) and an internal report is also gen- 
erated containing the results of the sweep (step 984). 
When the sweep is completed, the system returns to the 
system administration menu (step 906 in Figure 9A). 
[0090] Figure 9C illustrates the processing required to 
identify and flag discrepancies as discussed with 
respect to step 970 in Figure 9B. In particular, if an indi- 
vidual has a different last name, and is not a female hav- 
ing the same date of birth, the record is marked as 
containing a discrepancy (steps 971 and 972). If an indi- 
vidual has a different last name and is a female having 
the same date of birth, a marital status change is 
assumed and the record is not marked as containing a 
discrepancy (step 973). 

[0091] Figure 9D shows the main menu displayed for 
the client information management system process. A 
portion of the screen will display a list of selected claims 
related to the insurance plan (step 920). The user is 
also presented with a menu listing the client information 
management system choices (step 910). The menu 
includes options to perform a claim search (step 950), 
generate reports (step 940), alter the status of an indi- 
vidual from deceased to living (steps 930 and 931), and 
edit an existing claim or create a new death benefit 
claims (step 920). '#*§gg*?* 
[0092] If the user selects the creation of a new death 
benefit claim, a new claim record is created (step 921) 
using the individual's census data and the client's insur- 
ance policy information (step 922). The remaining 
steps, shown in Figure 9E, are the same as those per- 
formed when the user selects to edit an existing claim 
from the main menu. 

[0093] As shown in Figure 9E, financial transaction 
history information is retrieved (step 923) and the edit 
claim screen is displayed (step 960). The edit claim 
screen includes options to view general information 
about the claim, possibly to interface with other data- 
bases (steps 927 and 928), obtain a summary of claim 
financial transactions (step 926), view overall policy 
information (step 925). enter or edit insured data (step 
924) and create death benefit claim paperwork. 
[0094] If the user elects to create death benefit claim 
paperwork, the system will automatically generate a 
request for a death certificate (step 961). This includes 
a cover letter to the appropriate governmental records 
office, and the required fee, based on the zip code 
where the death occurred. After the death certificate is 
received (step 962), the information to process the 
claim is transmitted (step 963). Finally, once the insur- 
ance proceeds are received (step 964), the funds are 
distributed to the appropriate party through a wire trans- 
fer (step 965). 

[0095] Thus, the client information management sys- 
tem ("CIMS") module is designed to automate the proc- 
ess of handling death claims, insured information, client 
billings, accounting servicing and overall plan adminis- 
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tration. This is accomplished by providing a centralized 
database and interface that provides all necessary 
reporting and output to complete any of these functions. 
[0096] The CIMS workstation application is an appli- 
cation which runs on all current versions of Microsoft s 
Windows version 3. 1 and higher. The main interface is a 
"desktop", by which a plan administrator, accountant, 
financial analyst or sipervisor, can view the status of 
current claims in process, paid claims, policy, plan and 
insured information. Claims can be edited, inputting 10 
data as it is received, until the entire claim is processed. 
New claims can be identified to the system individually, 
or in a batch/sweep process, by matching the master 
insured list against databases of deceased individuals. 
The system allows a use to process a claim completely is 
in a single sitting, or step by step, as each required step 
is completed. The system tracks the status of partially 
completed claims, displaying the status of each claim on 
the desktop, and if desired, prioritizing claim activity by 
status, time since notification, or by client. The system 20 
allows the user to identify critical steps in the process, 
such as ordering and receiving documentation, auditing 
and transferring payments. The CIMS application gen- 
erates most of the paperwork involved in claims 
processing, and reporting on policy information. Death 26 
certificate orders, notification of pending and paid 
claims to clients and carriers, and cover l^erej^^^ 
forms, can be generated to the laser printers on the net- 
work. 

[0097] The CIMS application also handles the finan- so 
cial and accounting computations as well as policy data 
during the life of a policy. Premium payments, loans, 
withdrawals, cash values, interest calculations, and all 
transaction reversals, are all tracked by the system. All 
of these items are available for display, calculation and 35 
reporting at the earner level, client level, policy level and 
insured level. 

[0098] The overall system is built around a PC based 
Client/Server network architecture, utilising software 
and operating systems that will run on a variety of oper- 40 
ating systems. The database server runs an SQL data- 
base engine, and contains all of the data tables 
required. It receives data requests in the form of queries 
from workstation clients and returns the necessary 
information. It also schedules database backups and 45 
provides fault protection through transaction process- 
ing, and by being supplied by uninterrupted and condi- 
tioned power. 

[0099] The system also contains two other servers. A 
file server provides file and print sharing services, both so 
for the CIMS application, and other office functions, 
such as word processing. The file server also handles 
login authentication to the Local Area Network (LAN). A 
backup server is in place to backup data on the file 
server, and archive copies of the SQL database, for dis- 55 
aster recovery This server also provides fault tolerance 
by being able to stand in place of one of the other two 
servers, in the event of a hardware failure. 



[0100] PC workstations access the CIMS data engine 
via the LAN, and run a client application of CIMS, which 
formulates the data queries sent to the SQL server, and 
provide output and reporting to the end users. 
[0101] In preferred embodiments the invention com- 
prises a system enabling faster processing within the 
hardware implementation. 

[0102] Although preferred embodiments are specifi- 
cally illustrated and described herein, it will be appreci- 
ated that modifications and variations of the present 
invention are covered by the above teachings and within 
the purview of the appended claims without departing 
from the spirit and intended scope of the invention. 
[0103] The reader's attention is directed to all papers 
and documents which are filed concurrently with or pre- 
vious to this specification in connection with this appli- 
cation and which are open to public inspection with this 
specification, and the contents of all such papers and 
documents are incorporated herein by reference. 
[01 04] All of the features disclosed in this specification 
(including any accompanying claims, abstract and 
drawings), and/or all of the steps of any method or proc- 
ess so disclosed, may be combined in any combination, 
except combinations where at least some of such fea- 
tures and/or steps are mutually exclusive. 
[0105] Each feature disclosed in this specification 
^( includ ing anv^ accpmp anyjnq claims , abstract and 
drawings), may be replaced by alternative features 
serving the same, equivalent or similar purpose, unless 
expressly stated otherwise. Thus, unless expressly 
stated otherwise, each feature disclosed is one example 
only of a generic series of equivalent or similar features. 
[0106] The invention is not restricted to the details of 
the foregoing embodiments). The invention extends to 
any novel one, or any novel combination, of the features 
disclosed in this specification (including any accompa- 
nying claims, abstract and drawings), or to any novel 
one, or any novel combination, of the steps of any 
method or process so disclosed. 

Claims 

1. A computerised integrated insurance system 
method, comprising the steps of: 

inputting census data for a plurality of individu- 
als in the form of computer records; 
performing a pecuniary loss analysis based on 
pecuniary loss parameters and said computer 
records to classify said individuals into repre- 
sentative cells; 

preparing insurance illustrations based on said 
representative cells; 

performing a financial analysis based on finan- 
cial parameters and said representative cells; 
creating a final insurance contract and related 
documentation based on said representative 
cells; and 
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managing insurance information during the life 
of said contract based on said computer 
records. 

2. A computerised integrated insurance system s 
method, comprising the steps of: 

inputting census data for a plurality of individu- 
als in the form of computer records; 
analysing said computer records; and 10 
managing insurance information during the life 
of said contract based on said computer 
records. 



10. A computerised integrated insurance system 
method according to claim 9, wherein said step of 
performing a financial analysis can be repeated 
using modified financial parameters. 

11. A computerised integrated insurance system 
method according to claim 9 or claim 10, further 
comprising the step of creating a final insurance 
contract and related documentation based on said 
representative cells. 

12. A computerised integrated insurance system, com- 
prising: 



3. A computerised integrated insurance system 15 
method according to claim 1 or claim 2, wherein 
said step of inputting census data further comprises 

the step of comparing said computer records to 
prior census data. 

20 

4. A computerised integrated insurance system 
method according to claim 2, wherein said step of 
analysing said computer records further comprises 
the step of performing a pecuniary loss analysis 
based on pecuniary loss parameters and said com- 25 
puter records to classify said individuals into repre- 
sentative cells. 

5. A computerised integrated insurance system 
method according to claim 1 or claim 4, wherein so 
said step of performing a pecuniary loss analysis 
can be repeated using modified pecuniary loss 
parameters. 



a census analyzer (500) to input census data 
for a plurality of individuals in the form of com- 
puter records; 

a pecuniary loss analyzer (600) to perform a 
pecuniary loss analysis based on pecuniary 
loss parameters and said computer records 
and classify said individuals into representative 
cells; 

an illustrator (700) to prepare insurance illus- 
trations based on said representative cells; 
a financial analyzer (800) to perform a financial 
analysis based on financial parameters and 
said representative cells; 
a final contract generator (100) to create a final 
insurance contract and related documentation 
based on said representative cells; and 
an insurance information manager (900) to 
manage insurance information during the life of 
said contract based on said computer records. 



A computerised integrated insurance system 35 
method according to any one of claims 1 , 4 or 5, 
wherein said step of performing a pecuniary toss 
analysis calculates an insurable interest for each of 
said individuals in said input census data. 

40 

A computerised integrated insurance system 
method according to claim 4, wherein said step of 
analysing said computer records further comprises 
the step of preparing insurance illustrations based 
on said representative cells. 45 



13. A computerised integrated insurance system, com- 
prising: 

a census analyser (500) to input census data 
for a plurality of individuals in the form of com- 
puter records; 

an analyzer (600) to analyze said computer 
records; and an insurance information man- 
ager (900) to manage insurance information 
during the life of said contract based on said 
computer records. 



8. A computerised integrated insurance system 
method according to claim 7, wherein said step of 
preparing insurance illustrations includes adjusting 
said representative cells based on compliance with so 
insurance laws and regulations. 

9. A computerised integrated insurance system 
method according to claim 7 or claim 8, wherein 
said step of analysing said computer records fur- ss 
ther comprises the step of performing a financial 
analysis based on financial parameters and said 
representative cells. 



14. A computerised integrated insurance system 
according to claim 1 2 or claim 1 3, wherein said cen- 
sus analyzer (500) compares said computer 
records to prior census data. 

15. A computerised integrated insurance system 
according to claim 13, wherein said analyzer (600) 
further comprises a pecuniary loss analyzer (600) 
to perform a pecuniary loss analysis based on 
pecuniary loss parameters and said computer 
records and classify said individuals into represent- 
ative cells. 
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16. A computerised integrated insurance system 
according to claim 12 or claim 15, wherein the 
pecuniary loss, analyzer (600) can perform more 
than one pecuniary loss analysis based on modi- 
fied pecuniary loss parameters. 

17. A computerised integrated insurance system 
according to claim 12 or claim 15 wherein said 
pecuniary loss analyzer (600) calculates an insura- 
ble interest for each of said individuals in said input 
census data. 



managing insurance information with the com- 
puter system using information generated with 
said census data. 

24. A computer network comprising a plurality of elec- 
tronic numerical computers networked together, 
which network is adapted and configured to operate 
according to any preceding claim. 
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18. A computerised integrated insurance system 
according to claim 15, wherein said analyzer further 
comprises an illustrator (700) to prepare insurance 15 
illustrations based on said representative cells. 



19. A computerised integrated insurance system 
according to claim 15 or claim 18, wherein said 
illustrator (700) adjusts said representative cells 20 
based on compliance with insurance laws and reg- 
ulations. 



20. A computerised integrated insurance system 
according to claim 18 or- claim 19, wherein said 25 
analyzer further comprises a financial analyzer 

„ (800) to perform a financial analysis based on 
financial parameters and said representative cells. 

21. A computerised integrated insurance system 30 
according to claim 15 or claim 20, wherein said 
financial analyser (800) can perform more than one 
financial analysis based on modified financial 
parameters. 

35 

22. A computerised integrated insurance system 
according to any one of claims 15, 20 or 21 further 
comprising a final contract generator (100) to cre- 
ate a final insurance contract and related documen- 
tation based on said representative cells. 40 

23. A method for implementing an integrated insurance 
system using a computer system, said method 
comprising the steps of: 

45 

receiving census data for a plurality of individu- 
als into the computer system; 
performing a pecuniary loss analysis based on 
pecuniary loss parameters and said census 
data to classify said individuals into represent- so 
ative cells; 

preparing insurance illustrations based on said 
representative cells; 

performing a financial analysis based on finan- 
cial parameters and said representative cells; 55 
creating a final insurance contract and related 
documentation based on said representative 
ceils; and 
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